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context transfer in a communication network comprising plural 
Heterogeneous access networks 

Field of the Invention 

The present invention relates to a method for a context transfer in a . communication, 
network: comprising a plurality of heterogeneous access networlcs, wherein a mobile 
temiinal is attached to one of the access networlcs. Further, the present invention relates 
to a context transfer.manager performing the method. Moreover, the present invention 
relates to a mobile terminal specially adapted to perform the provided method for context 
transfer. 

Background Art 

Every moving mobile node that is connected to a network may perform a handover to a 
new network at the time when it leaves the coverage area of the old one to sustain 
connectivity. If the mobile node has. an ongoing data session oven the .connection than . 
the connection will brai<e at least for the time of the handover process. Additional 
mechanisms like MobileiP can allow rerouting the traffic to the new point of connection 
so tiie session may be resumed, i-iowever, the handover duration is th@ lower time limit 
for the session discontinuity. 

It is therefore appreciated to keep ttie handover duration as short as possible. A 
mechanism to preserve this is pro-active context transfer. Pro-active Context-Transfer 
allows establishing a session state in an .access router (AR) or access point (AP), before 
the mobile node (mobile terminal) starts a handover to new network. The transfer is done 
through the backbone network the access router or access point is connected to. This 
could be for example the Internet 

. The origin of the transferred data is an entity that has already knowledge alDout the 
context. In. an alternative solution for the pro-active context transfer, the so-called 
reactive context transfer, the transfer of the context is. started when the handover already, 
has begun. 

An importarit function to realize a pro-active context transfer is the selection of 
.candidates to which the context is transferred before performing the handover, it is 
normally not predictable, which access router or access point is the next point of 
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connection as the movement pattern of the mobile node is unl<nown. Generally, It is 
assumed that the cell coverage areas of the access points overlap such that a handover 
may be perfomned. However, if there are multiple new access points In reach this also 
gives only litHe help for the selection process of the new network to join. 

Seamoby.CTP and CARD 

The IETF (Internet Engineering Task Force) working group Seamoby has developed two 
protocols concerning context transfer. These are the context transfer Protocol (CTP, see 
Loughney et al., "Context Transfer Protocol", Internet Draft, October 2003, all Internet 
Drafts and RFCs available at http://www.ietf.org) and the Candidate access router 
Discovery (CARD, see Liebsch et al,, "Candidate Access Router Discovery", Internet 
Draft September 2003). CTP serves as the protocol to initiate the context transfer and to 
carry the context data. Tliree parties are involved in the CTP communication, the mobile 
node (mobile node), the pre>dous access routier (pAR) and the next access router (nAR). 
M\ three, with different message types, can initiate the protocol exchange. If rnbbile node 
wants to or has to change ite point of rietwork access it sends a request at least to the 
n^ access router, in. case it is.ajready dlsconnactpd ^m previous ac(^ss router. If the 
mobile node us^ some sort of next access router prediction, maybe thtx>ugh CARD, it 
even sends a nriessage to the pre>^ous access router starting context transfer to the 
predicted next access router before connecting to next access router itself. It contains 
the IP address of the n«ct.access router, mobile node's old IP address on previous 
access routei-, a list of to be transferred context data, the possibly known IP address on 
niext access router and a flag requesting secure and/or reliable transfer of context. The 
context data., call^ "feature contexf , is then sent in a further message. 

The CARD protocol consists of only two messages, tiie CARD request and the CARD 
reply- They even can be used between two access routers, the possibly next access 
-router~(nAR)*and- the current access router, called previous access -router (pAR), or 
between a mobile node and a previous access router or next access router. Between 
access' routers, CARD helps to getTcapability information of the next access router 
candidates that is needed to select the most suitable one for context transfer and later 
mobile no6e handover. Between mobile node and previous access router a CARD 
request is issued to demand a list of next access router candidates. In this request the 
mobile node can send any next access router data link layer (Layer 2) identifiers it might 
have detected by some mechanism, so the previous access, router has a hint, which 
access router is in range of the motile node. The way the previous access router 
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identifies a next access router by its Layer 2 identifier is not specified in the CARD draft. 
In the reply, to the mobile node previous access router sends a next access router list 
with the belonging next access router capabilities that could have been pre-filtered by a 
previous access router determined criteria to reduce the number of next access routers 
the mobile node has to process as candidates. 

Context transfer in Wireless Local Area networks (IEEE 802. 11 f) 

In Wireless Local Area networks (WLAN) information about the client or station (STA) 
between the access points (AP) involved in the handover aliov\4ng the re-association 
process at the new access point are exchanged. A context transfer schenie to. accelerate 
this re^ssodation . process is used. Two functional entities, the accese point and the 
RADIUS server ard . involved in the context transfer. For the .stetion (STA) the' 
management process is transparent The RADIUS server fulfils the task of mapping 
delivered Basic Service Set identifiers (BSSID) to IP addresses or Fully Qualified 
Domain Names (FQDN) of access points, this mapping implicitly shows if an access 
point belongs to the same fended service set (ESS) as the RADIUS server.. It also 
distributes on request cipher keys to the access points to allow encrypted communication 
between two access points. The communication includes all management data that 
allows the movement of clients between the nodes and enforces the association of a 
client only with one access point at a time; The management, messages can contain 
context data: Each access point in an ESS folio>Adng maintains a dynamic representation 
of its neighboring access points. This representation is also referred to as the Neighbor 
Graph. 

Important to note is that in the IEEE Draft IeeE 802.1 1f-D3 "Recommended Practice for 
Multi-Vendor Access Point; Interoperability via. an Inter-Access Point Protocol Across 
Distribution Systems Supporting IEEE 802.11 Operation", January 2002, states- in the 
ann^ B, section 6.3.1* that context transfers between media with different service 
models should not be expected to be successful. Attempts to transfer context between 
cellular devices and IEEE 802.11 access points according to the IEEE 802.11 context 
transfer mechanism will fail unless the cellular access points implement the same set of 
services as the 802.11 access points. In conclusion the document states, that context 
transfers between heterogeneous technologies will fail. 
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Other mechanisms 

Additionally to the access router and mobile, node of the CTP scenario/ the mechanism 
described In US 2003/0,103,496 A1 comprises a Policy Server (PS) that serves the task 
of retrieving the neighboring acqess networits (AN) and access routers capable of a 
context transfer (comparable to CARD mechanism). The access networks are Indicated 
by Layer 2 Infomiatlon In beacon signals, received by the mobile node, and looked up In 
a. local database by the PS. Ttie PS communicates with neighboring Policy Servers If 
they are capable to serve the mobile node and pre-authentlcates it with them. One 
drawback of this mechanism is that it needs even more secured connecUons (of SeciirHy 
Associations In other tenns) than the CTP scenario. Next, it does construct the context, 
from a dynamic and static part before Sending to the new access networtc, but It does noj 
take Into account any features or capabilities of the target network. 

US 2003/0,092,444 A1 d^cribes a mechanism that takes dynamic parameters like 
current traffic load and user rights Into account for selection of neighboring candidates. 
The list of candidates may differ therefore for each mobile node. The transfer process 
Itself is. perfbrmed between the access jrouters of the access netv«)riis. 

A mechanism for discovery of neighboring access routers, useable for a context transfer 
mechanism, is presented in US 2003/0,087.646 A1 and Is abbreviated GAARD. It allows 
detecting geographically neighboring access networi<s even If they are not topologically 
neighbors considering e.g. IP addresses. In this document, a mobile node has a local 
cache of l^yer 2 (data link layer) addresses and Layer 3 (networtc layer) addresses. 
When the mobile node receives a beacon signal with a Layer 2 address and wants to 
initiate a context transfer to this node, It looks up the corresponding Layer 3 address in 
Its cache. If the cache lookup fails, the mobile node requests the serving access router to 
lookup the conesponding Layer 3 address. The access router itself looks up Its cache. If 
the-address is not found; it starts-a dynamic discovery process to derive the requested 
Layer 3 address. The access router returns the address to the mobile node that In turn 
uses It.to start a context transfer or other handover mechanisms to the Identified access 
router. The. functionalities of this system must exist In every access router and mobile 
node that wants to. use or support this system. The mechanism can serve as an 
Implementation of the CAI^ process. 

In contrast to the generic context transfer scenario, where all nelgliboring access routers 
are even possible points of access for a mobile node, the latter assumption is not true In 
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a scenario of networks, working together on a contract base. A neighboring access 
router may belong to a network operator without a roaming agreement with the mobile . 
node's home operator. So the mobile node receives beacons of the forieign network but 
an authentication process will fail, as the Authentication Authority in the foreign network 
is unable to connect to the home AAA (authentification, aiuthorization and accounting) 
server of the mobile node or at least will not trust this unknown server. A context transfer 
to such a network wiir also fail for the same reason. 

A way to integrate networks without a direct roaming agreement with the rnoblle node's 
home operator is the use of proxy AAA servers. The access network operator trusts the 
proxy AAA server of an operator that Itself trusts the home operator of the mobile node. 
This way the mobile node can be authorized eyen in this foreign network. 

jt IS probable that mechanisms like the context transfer In WLAN are developed also for 
other local area network technologies. Context transfer between topologlcally adjacent 
entities has the advantage of short distance, and this. way low latency transfers. 

Associated with the previous issue is the fact of a heterogeneous access network 
.structure. It is very likely that a moving mobile node's context cannot be regarded as' 
static data. It will change as the access network infrastructure of the new point of access 
differs from tiie previous one. The simple forwarding of context data to the new access 
network will not solve this issue. 

A general problem of context transfer is the trust relationship between the entitles 
involved in the context transfer process. In a scenario with an area containing a number 
of n neighboring gccess routers, transferring context data between each other, this gives 

an upper bound of ^ ^ trust relationships between all the access routers. As these 

relationships are technically represented by some cipher key exchange between peers to 
allow encrypted communication, a large number n means a lot of storage space for key 
data sets, in the example «-l data sets per access router. Also these relationships 
must be established before context transfer Is possible between the peers, requiring a 
management function. A method to reduce the number of trust relationships would 
therefore save storage space and management effort. An already existing technology for 
secure data transport is IPSec naming the trust relationships Security Associations (SA). 

A mobile node, in most cases, vwll be connected to its point of access t)y a wireless link. ' 
These links normally have lower bandwidth than wired links in the backbone part of. the 
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access network and the Interconnection of the. different access networks. This leads to 
higher transfer cost pier arnount of data In the wireless domain. 

Another aspect Is the pow^r consumption of the mobile node. The consumption is 
directly conelated with the number of send packets to the wireless link. Both aspects 
lead to the. objective to keep the amount of management traffic as low as possible, 
compared to the user payload traffic. 

• * * 

Summary of the Invention 

The object of the present invention is to solve at least one of the problems stated above. 

The object is solved by the subject matter of the independent claims. Prefened 
embodiments of the present Invention are subject matter to the dependerit claims. 

• * • ' ' - . ■ * , » 

According to a first embodiment the present invention provides a method for a context 
transfer In a communication network comprising a plurality of heterogeneous access, 
networks. A motnie tenninal may be attached to one of the access networks. 

Accordlng'to this proposed method, a context transifer manager may receive location 
information and may detemnlne neighboring access networks for the mobile tennlrial 
. based on the location infonnation. Further, ttie context transfer mariager may generate at 
least one context for the neighboring access networics and tiie mobile terminal and 
transmit a context to each of flie neighboring access netwoilcs and the mobile tenmlnal. 

The generation of Vne at least one context may be based on capabilities and parameters 
associated to the. mobile client and capabilities and parameters of the neighboring 
access networks ^Idng into account the respective access technology, arid tiie context 
transfer manager may be common to the plurality of heterogeneous access networks In 
the communication network performs tiie context transf«s related to flie rriobiie .station. 

Hence, the present Invention according to tiie first embodiment allows a context transfer 
even In case the mobile tenninai perfbrnis a handover between access networks 
employing two different access technologies. Also when consWering tije access 
technologies used In tiie candidate access networks to which ttie mobile terminal rnay 
move. I.e. ttie neighboring access networks, a dynamic context may be generated which 
may be adapted to the i^ec^ye protocols used by diffianent access technologies. This 
Is. also facilitated by employing a common context transfer manager In tiie 
communication network since only the common context transfer manager may tiransfer 
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the context to context managers In the different candidate access networks which 
requires far less security associations in the network. The benefits from the proposed 
architecture of the present Invention will be outlined In more detail below. 

According to a further embodiment, the mobile terminal receiving a beacon signal 
indicating, the presence of another access network, performing a handover from the 
current access network to the new access network from which the beacon signal is 
received. 

The cohtext generated for each of the neighboring access networks and the mobile 
terminal may comprise a static or temporary kJentifier of the mobile terminal. The static or 
temporary identifier may e.g. be used by a context manager in a new access network to 
associate the mobile terminal to Its context received from the context transfer manager. 
The latter may be facilitated if the mobile terminal includes the static or terhporiary 
identifier In the data transmitted to the new access network. IHence, by the inclusion of 
the Identifier in a message transmitted to the context manager in the new acce.ss network 
the proposed method may facilitate the mapping of the context (previously) received from 
the context transfer manager to the mobilie terminal. 

The context received by the mobile terminal may also be used by same to pre-configure 
the mobile terminal based on the context received from the context transfer manager. 
Hence, e.g. by a pre-conflguration of the network interfaces this process does not need 
to be performed when upon the mobile terminal connecting to a new access network. 

The context transfer manager may further receive status Information from the mobile 
tenminal, wherein the status information indicate the quality of service achieved in the 
current access network and/or indicates unsuccessful access attempts to at least one 
other access network than the current access network. 

Hence, this information gathered by the context trarisfer manager may be used by same 
to adapt several decision processes In the context transfer manager based on this 
Information. E.g. the detennining of neighboring access- networks, may also.empioy a 
selection algorithm which may be adapted based on the status information from the 
mobile tenminal. 

Anottier possibility wpuld be that if clients report a connection failure to an specific 
access network, the latter may no longer be considered in the determination process of 
neighboring access networks and/or an appropriate error message may be generated 
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which may be addressed and handled by the access nietwork's operator or the context 
transfer manager's operator. For the latter purpose, the context transfer manager may 
store Information on failed access attempts to access networks reported by the mobile 
temiinal. 

The capabilities and parameters considered during context generation and associated to 
the mobile client may comprise at least one of static and/or temporary temfilnal 
Wentiflers. user preference^ the requirements for the tennlnal's communications, 
guaranteed service quality parameters, and/or access pemnlsslons to services, session 
d£ita comprising encryption keys, seeds, ciphers and/or header compression information, 
terminal capabilities comprising information on the display, network interfaces, 
processing power, supported applications and/or video/audio codecs. As becomes 
obvfous, several acctess netwtoric specific parameters which may address different 
access tedinoiogles in the access neftworks may be used to generate a dynamic context. 
The same also applies to the capabilities and parameters of the neighboring access 
networics comprise which may comprise at least comprise at least one of access 
technology specific attributes comprising a radio frequency, data rates, channels, and/or 
coding schemes, access networic spedfTc attribute comprising cryptographtc capabilities • 
of the respective access networtc, an access networi? Identifier, supported quality of 
service mechanisms, available traffic classes, local services. Information portals, and/or 
public transportatton information. 

The location Infbnnatton received by the context transfer manager may be received in a 
paging message transmitted by the mobile terminal, from an authentication procedure 
performed between the mobile terminal and an authentication server or by an entity 
located in the access networic to which the mobile temiinal is connected. Taking the 
second example, a mobile tenninal that perfomis an initial authentication procedure for 
the access networic to join e.g. with the associated AAA server may provide location 
'information to the AAA server. This-iflfefmation may be also available to the context 
transfer manager such that same may use the location infomiation from the 
authentication procedure to detdmiine iielghboring access networits. Further, the context 
transfer manager may also Initiate a context transfer In response to the authentication 
procedure of the mobile terminal. 

Further, the location Infomiation may be based on a geographical location obtained from 
a location determining device, e.g. a GPS receiver, or a networic related location 
determined based on a networtc address and/or networic prefix. Taking as an example 
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the usage of the IP protocol, . the network address corresponds to an IP address while the 
network prefix would be the subnet mask. 

According to a further embodiment of the present Invention, the handover of the mobile 
terminal may be perforrned upon having received context infomiatlon from the context 
transfer manager related to the new access network. Hence, also a pro-active context 
transfer may be realized by the employing the present invention; 

For the description of the context generated, a markup-language based data format may 
be employed. Further, this fonmat may also be used to describe the context transfenred 
from the context transfer manager to the plurality of access networks and the mobile 
terminal. 

In another embodiment of the present invention an authentication server In a neighboring 
access network receiving the context from the context transfer manager may perform a 
registration and/or authentication procedure of the mobile terminal with access netwodk 
using the received context information. Further, the registration and/or authentication of 
tiie mobile terminal may comprise a registration of a security key of the mobile terminal. 

The mobile terminal may use the registered security for communication upon attaching to 
the neighboring access network in which the security key has been registered. 

Anotiier embodiment of the present invention considers tiie. situation in which the mobile 
terminal is attached to a foreign ' communication network. I.e. a so-called visited 
communication network. In this embodiment, the context transfer manager may reside in 
a visited communication network. In the present invention a communication network may 
be interpreted as an. administrative domain, i.e: a network comprising at least one core 
network and a plurality of access networks of an operator or of access networks of 
providers having sisrvice level agreements with the operator. Hence, this embodiment 
may Be related to situations Tn ' which the mobile tert^ resides in anotiier 
administrative domain than its home domain. 

in order to allow the visited context transfer manager, i.e. the context transifer manager in 
the visited communication network to generate an appropriate context for context 
transfer, tiie context transfer manager In the home network of the mobile terminal may 
transmit data relevant.for the generation of the at least one context to the context transfer 
manager of the visited communication network. 
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Further it should be noted that a context manager In ah access network may receive the 
context from the context transfer manager, wherein the context manager maintains no 
connecUon to another context manager In another access network. Hence; the context 
managers In the different access networks may not need to maintain a connection to 
each other and to transfer or fbnward the context to each other directly - if posslble'at all - 
but may receive the context from an entity on a* higher hierarchical leyel, the context 
transfer manager. 

Another, embodlrhent of the present invention provides a context transfer manager in a 
communication network comprising a plurality of heterogeneous access networks, 
wherein a mobile terminal is attached to one of the access networks. The context 
transfer manager tnay comprise receiving means for receiving location Infomnation, 
processing means for determining neighboring access networks^ for the mobile tertninal 
bassd on the location infonriation. Context generation means for generating at least one 
context for the neighboring access networks and the mobile tenninal, and transmitting 
means for transmitting the respective context to each of the neighboririg access networks . 
and the mobile tenninal. Kurlher, the oontexl generation means may be. adapted to 
generate the at least one context based on capabilities and parameters-associated to the 
mobile client and capabilities and parameters taking Into account the respective access 
technology of the neighboring access network. Moreover, tiie context transfer manager 
common to the plurality of heterogeneous access networks In the communication 
network may perfonn the context transfers related to the mobile station^ 

The context transfer manager may be adapted to perfonn any of the metiiods described 
above. 

In a further embodiment of the present Invention, a mobile tenninal adapted to perfonn 
one of the methods above is provided. The terminal may be adapted In that It may signal 
failed access attempts4o. access networks to the context transfer riianager or In that it. 
may receive context infonriation provided in a markup language format. 

Brief Description of the Figures 

. In the following the present invention is described in more detail In reference to tiie 
attached figures and drawings. Similar or conesponding details in the figures are marked 
with the same reference numerals. 
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Fig. 1 shows a simplified structure of a context transfer from a home domain through 
a proxy of a visited domain to a WLAN according to one embodiment of the 
present invention, 

Fig. 2 shows an architectural overview of a communication network managing a 
. context transfer for a mobile node according to an embodiment of the present 
invention, 

Fig. 3 shows a context generation process according to an embodiment of the 
' present invention; 

Fig. 4 shows a context transfer ptacess from an external AAA server with context 
transfer ' functions to an Authentication Server (AS) or access router of a 
WLAN according to an embodiment of the present invention, 

Fig. 5 shows a flowchart of a context transfer process according to an embodiment 
of the present invention, and 

Fig. 6 shows an architectural overview of . a communication network managing a 
context transfer for a mobile node attached to a visited network according to 
an embodiment of the present invention. 

Detailed Description 

An architectural overview of a communication network that manages the context transfer 
for a mobile node according to an embodiment of the present invention Is shown in Fig. 
2. The architecture is distributed across the network of the mobile node's home domain, 
the mobile node 207 iteelf and the access network. 

A context transfer manager (CTM) 200 may be collocated with tiie AAA server 206 of the 
home domain. The context transfer manager 200 may send appropriate, dynamically 
created context data to the neighboring access networks of the mobile node's current 
position. These neighbors are detected by a neighbor locator 202 function that got the 
cuhreht location of the mobile node 207 (e.g. IP address or network prefix) from the 
context transfer manager 200 and are retumed In a neighbor list This neighbor list 
together v^th information about the user of the mobile node 207 may be provided to the 
context generator 201. The context generator 201 may maintain databases about 
capabilities of the access networks and mobile nodes and about context formats (see 
User Proifile Database 203, Access Network Context Database 204, Neighbor 
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Capabilities database 205). Based on this Information, a suiting context. e.g. tal<ing Into 
account the distinct terminal identifiers, subscription infbnnation, user preferences; 
terminal capabilities. Quality of Service parameters, encryption and compression 
information, access technology specific attributes or access network specific attributes, 
may be generated for each neighboring access network. This context may be then 
transfenred to the access networics In a pro-active way, where it is Instantiated by the 
context manager (CM) 209. 210, 211 of the access networic (AN). The mobility manager 
208 function on the mobile node 207 may also be Infonned of the neighboring networks 
220, 221, 222, Including the information that Is needed to perform an accelerated 
handover to them, using context transfer. Based on the context received from the context 
transfer manager 200 the mobile node 207 may (pre-)conflgure Ite network interfaces for 
the next points of access. The mobile node 207 itself may make the handover decision, 
when It receives beacon signals of a neighboring network In reach. 

Wh^ the mobile node 207 is roaming to a foreign domain, the context transfer 
management may be done by tiie context transfer manager 600 of the visited operator 
(see Fig. 6). The context transfer process is similar to the non-roaming case, only adding 
a handover of the management firom the honie cont^ transfer manager 200 to the 
visited context transfer manager 600, 

Next, the context transfer manager 200, 600 will be described In more detail. The main 
Instance for context handling miay be the context transfer manager 200, 600 (CTM). It 
may control the functions having access to the needed context Infonmatlon. In the 
architecture functions to control may be the context generator 201. the neighbor tocator 
202, the access networic (AN) context manager 209, 210, 211, 609, 610, 611 and the 
moblHty manager 208 function. At first the context transfer manager 200, 600 may 
receive the current location of the mobile node 207 through the communication with the 
mobllity manager 208 or by rnearis of standard authentication procedure e.g. v\rfien a 
rnoblle temilnal 207 Is turned on and attaches to the access network. 

The context transfer manager 200,^0" may then detemiine all neighlx>ring access 
networi(s 220, 221 , 222, 620, 621 , 622 of the mobile node 207 using the neighbor locator 
202, 602> Next, the context transfer manager 200, 600 may signal the context generation 
function 201, 601 to retrieve the user information relevant for the context used by the 
neighboring access networits 220, 221. 222, 620. 621. 622 of the mobile node 207. The 
signaling may comprise a user ID and an applicable networic ID for the neighboring 
networtcs 220, 221. 222, 620, 621, 622, such as a network prefix. Another parameter 
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included in the context may be an additional unique static or temporary identifier for the 
user that the access netwoFl< may use later for off- or online charging of delivered 
services. One may think of the IMSI (International Mobile Subscriber Identity) in GSM or 
UMTS or possibly a pseudonym NAI (Network Access Identifier, see Aboba et al.» " 
Network Access Identifier", RFC 2486i January 1999) usisd as a static or temporary 
identifier, respectively. 

After the integration of this information into the context data, the context transfer 
manager 200, 600 may send the context data to the access netv\^ork context manager. 
209, 210, 211, 609, 610, 611 and parts of this generated context Infonnation to the 
mobility manager 208 of the mobile client 207 (mobile terminal). These parts of 
infomnation may enable the mobile node 207 to configure its network interfaces and to 
use the correct identifier on following neighix)r network access attempits. 

In addition to the tracking Infomfiation of the mobile node 207, the context transfer 
manager 200, 600 may also accept status information from the mobility manager 208. In 
the status Infonmation the mobile node 207 may signal reached Quality of Service (QoS) 
in the. current network or complete failure of access to another access network. Jhis may 
allow dynamic adaptation of the selection algorithm for the best-suited access networks 
in the neighbor list, helping other mobile nodes moving in the same area to select an 
appropriate new access network. In this way the mobile node 207 may serve as a 
network probe gathering information on the network status. If many mobility managers 
signal the failure of the context assisted handover in a single access network, the context 
transfer manager 200, 600 may inform a management and operation function of its own 
network to further investigate this error or may inform the operator of the access network. 

Further, the context generation function in the context generator 201 will be discussed in 
further detail in the following. As stated above, the basic Seamoby CTP scheme has 
restrictionsr when^it IS implemented in heterogeneous networks or networks in different 
administrative domains. This belongs to the creation of a 'context*. A context may not be 
•a set of pure user-related data alone, like identity; password or encryption key. 
Particulariy it may further describe the state of the networic, seen from the perspective of 
the client. The information on the network status may for example comprise access rights 
to network services, an encryption algorithm for transported data, a routing policy for the 
user data, a traffic class assigned to the users session traffic or accessible network 
entities (DNS server, default gateway, etc), in a single administrative domain it is 
possible to keep this data static throughout the whole network, if demanded by the 
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operator. Crossing the Iwrder to other domains, this data may be changing or, so to say, 
may get dynamic. A very tight coupling between the operators may be needed to prevent 
this, if ever possible. Hence, the approach suggested by the present Invention to make 
the context transfer adaptive to these dynamics is of advantage and solves above stated 
problems. 

A context generation process adcording to an embodiment of the present invention is 
shown In Fig. 3. The context creation process may be split Into four parts, two source 
data objects, one processing function and one resulting data object The two static data 
objects represerit. the user parameters 301 (including terniinal parameters and 
capabilities) and network parameters 302 and capabilities. Based on these two. 
parameter sets, the processing function 303 may derive the resulting data object, i.e. the 
dynamto context 304. Since,, network related parameters also depend on: the access 
technology usal in a respective access network, the contexte Ibr access networks 
having different access technologies may vary. As an example, imagine several 
algorithms InsWe the processing function that produce session encryption keys, state 
flags or user-id handles. The data object for user parameters may comprise a description 
of the user Identify ihdudihg temporary iddrititlegi user preferences . like QoS 
requirements or allowed session types (e.g. video, voice), encryption keys or seeds and 
Installed ciphers and temtilnal capabilities like screeri resolution, processing power, 
audio/video codecs and applications available, network interfaces, etc. 

Not only contect relevant data may be Included in tiie data object This favors the use of 
a generic user data storage eventually existing for other purposes (e.g. Generic user 
piofile GUP. of 3GPP). The data object for networic parameters may comprise information 
on the specific access network to ttiat the resulting context may be transfenned later. 

Considering user specific and/or tenninal specific parameters as well as parameters 
depending on the respective access technology of the next access- network it may be 
possible to create a dynamic context which may preventing a failure of a context transfer 
in case ttie mobile temiinal 207 accesses-a new network. It could be data like supported 
cryptographic algorithms or a WLAN SSID (service set identifier) included in networi< 
beacons, helping the mobile node 207 to identify \he WLAN to choose. Again not only 
context relevant data may be included In the data object 304 (context), but also data sets 
belonging to other applications that use the object. In general a XML derived language 
may be used to describe context data for example being used for ttie GUP or for ttie 
Composite Capabilities/Preferences Profile (CC/PP). The W3C languages XPath and 



15/30 



XQuery for data search and selection inside a XML document and XSL may be 
employed. XSL may be used to transfonn XML documents and post-process them into- 
arbitrary output formats. Additionally, the usage of a markup language to describe the 
context information may be employed to extend the data description in a safe and easy 
way, staying compatible to older descriptions. As the on-dernand context generation may 
solve the issue of context transfer to incoherent networks, it may additionally proyide the * 
capability to keep some or all user or network parameters dynamic. A user may change - 
his/her user preferences, the forthcoming next context transfer in the conimunication 
network may' Immediately adapt to the new preferences (higher session QcS, new 
encryption mode, etc.). 

The mobility manager 208 In the mobile terminal 207, beside others, may control the 
network Interfaces and may track the movement of the mobile node 207. Therefore the 
best location may be the mobile node 207. Alternatively, the access network may also 
track the mobile node's location based on the terminal's movement when changing from 
one access point to another. In case of the mobility manager 208 being located at the 
mobile node 207, the status information may be included in. paging messages 
transmitted from the mobile client 207 to the- context transfer-manager 200; The mobility- 
manager 208 may signal the movement and position of the mobile node 207 to the 
context transfer manager 200. Therefore it can use information, gathered by a built-in 
position determining device, such as a GPS (Global Positioning System) receiver or e.g. 
by evaluating received network beacons or Router Advertisements received. 

The location may be represented by a geographical or a virtual, i.e. network related 
location. Multiple formate, for describing the mobile terminal 207s location may be 
supported, to 9llow. different techniques to be Implemented In the mobile node 207 and to 
get different infonmatlon from the diverse location' representations. This is motivated by 
the fact that a single technique does not fit all needs. GPS for example may provide 
hlgFily^TOu^^ location irifoTfriaiidn on tKe ferififriaTsTocaWbn direiot line of " 

sight to the GPS satellites for location calculation. Especially in cities with a high skyline 
this may sometimes be impossible to obtain. The network-related location (e.g. network 
address and prefix) of a mobile node 207, as another example, may help to gather 
infonmatlon about the network, the mobile node 207 is connected to (e.g. to get the 
address of a access server). But the single network address of the mobile node 207 has 
not to be similar to the address of a geographically adjacent network. An additional 
mechanism may therefore be used to compute the neighbors to a given network address 
(e.g. Neighbor Graphs). 
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The network control part of the mobility manager 208 may be enabled to pre-oonfigure 
the netwwjrk interfoce(s) of the mobile node 207 with the Information, received inside the 
context from the context transfer manager 200. Tlie network control part may hokJ the 
different configuration presets for any of the signaled neighboring acdess networks inside 
a local cache and may Instantiate the appropriate one, when It detects a handover 
situation. The handover may be actively started by the mobility manager 208, If it 
detemiines the need for switching, e.g. an application may need a higher bandwidth or 
the current connection may be fading. 

The mobility managar 208 may further solve the task of communicating a change in the 
users preferences on network connection or QoS requirements to the context; transfer, 
manager 200. These preferences influence the selection of suitable network neighbors 
and the context generation process. 

The access network context manager 209, 210, 211, 609, 610, 611 (AN context 
manager) may process the received context data. In this process, the access, controlling 
entities. I.e. the Access Servers 212, 213, 214, 612, 613, 614 In the access networks 
220; 221, 222, 620, 621, 622 (see Fig. 2 and 6) may be configured for the possibly 
moving mobile node 207. The configuration process may be transparent to the outer 
network and to the context transfer entity that sent the context. The only requirement 
may be ttie usage of a defined template, describing the context fomnat that the context 
generator 201, 601 in the context transfer manager 200. 600 may fill out and which the 
access network context manager 209, 210. 211, 609. 610. 611 may understand and 
instantiate. Intemal information about the network can be included, as both sides have a 
tnjst relattonship td protect against an abuse of the context transfer data. The intemal 
access network configuration by the access network context manager 209. 210. 211. 
609. 610. '611 may include an access network v»rtde context transfer mechanism to allow 
the acceleratton of Intra-domain handovers. 

The neighbor locator 202. 602 may retrieve the neighbor access networks of the mobile 
node 207. The neighbor locator 202, 602 may obtain the mobile node^sjocatlon from the 
context transfer rrianager 200. 600 beforehand. With the location infomiatlon it may look 
up a network representation that stores neighbor relationships (see databases 203. 204. 
205 In Fig. 2 or databases 603, 604. 6()5 In Fig. 6). The representation may be dynamic 
or static. 
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Seeing WLAN as an emerging technology for wireless broadband access in public and 
company areas, the 3GPP identified the requirement of an interworl<ing mechanism . 
between WLANs and 3GPP cellular networl<s. Therefore, the 3GPP has defined six 
different scenarios that describe service levels supported by a WLAN intenvorking with a 
3GPP network. 

In the 3G-WLAN Intenvorking scenario there exists a centralized AAA structure with the 
Diameter servers. This structure also has Security Associations (SA) that could be 
reused for the securing of the context transfer* here between visited public land mobile 
network (VPLMN), home public land mobile network (HPLMN) and. WLAN access 
networks. The present invention may provide a chained trust relationship between the 
home and visited context transfer manager, such that a successful context transfer to the 
foreign network may be possible. Therefore a context transfer solution for this scenario 
may implement proxy functionality foir context transfer, building a system for hierarchical 
context transfer. Fig. 1 shows the simplified structure of a context transfer from a home 
domain (e.g. HPLMN) through a proxy of a visited domain (e.g. VPLMN) to a WLAN 
where the context is processed and instantiated. 

The access router-to^access router context transfer scenario, i.e. the context transfer 
from the previous access router (pAR) to the n^ access router (nAR) may therefore be 
changed. 

The three involved entities according to the present invention may now be the mobile 
node 207, the next access router and the AAA server 206. The mobile node 207 may 
transmit a context-transfer request to the AAA server.2b6. Upon this, the AAA server 206 
may transfer the context of the mobile node 207 to the next access router. This may 
recommend a trust relationship betiA^een the next access router and the AAA server 206, 
which already exists if the WLAN AR operator has a roaming agreement with the AAA 
server 206 operator. Given m as the number of roaming partners.- this leads to m 
security associations per each of n access routers and n^m security associations over 
all. 

This number should be substantially lower than in the access router-to-access router 
context transfer scenario. Another benefit is that a CARD-like functionality in the access 
routers may no longer be needed as the AAA server 206 does the neighbor discovery. 
Only a context transfer agent may be present in the access routers. In general the 
neighbor discovery functionality may be invisible to the network and may therefore be 
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implemented In a vendor specific way. Even the problem of Incompatible context data 
between two access routers, expected at least at vertical handover between different 
administrative domains, may be faced more efficiently with the AAA server 206 imitating 
a previous access router. 

In case the. AAA server 206 has exact knowledge of next access routers capabilities 
through the neighbor, discovery process, It may dynamically adapt the context to the 
capabilities of the targeted niexl access routers. Having access to the complete user 
profile It may be possible to create a suitable feature context in opposite, to the Inter- 
atibess router contract transfer that has only a reduced set of irifomnation. . 

A mobile node 207 that roams in a foreign or visited domain (e.g. VPLMN) may not be 
assisted by tfie home context transfer manager 200 directly, as the context transfer 
manager 600 may have no or not suffTdent Information about the access networks 621, 
622 of the foreign domain. The home context transfer manager 200, i.e. the context 
transfer manager 200 in.the.horpe domain of the mobile client 207, may not be able to 
generate context data for the Access networks. Hence, the mobile node 207. may be 
. .assisted by the, context transfer, manager 600. of the foreign domain, J.e; by the visited 
context transfer manager 600 (VCm^. To allow the VCTM 600 to assist, the home . 
context transfer manager 2(K) (HCTM) niay deliver the needed parts of the mobile node's 
or user's profile ^. ttie VCTM 6CK). 

Fig. 6 shows the network's architecture for a home and visited domain controlling 
individual access networks. A context transfer manager 600 in a visited domain (VPLMN) 
may have the possibility to tailor the received data for a targeted accesis point or access 
network. Like the context transfer manager 200 of the home operator the VCTM 600 may 
maintain databases 603, 604, 605 about the access networks 621 , 622 that have Service 
Level Agreements (SLA) with its own operator, about their capabilities and their required 
context fomiat Further, the visited context transfer manager 600 may also retrieve 
information from the AAA server 606. The difference for a coritext transfer manager 600 
in a VPLMN (VCTM) ser^Hng«^mobiletK>de-207 and its mobility manager 208 may be the 
non-permanently stored user profile for the roaming mobile node 207. 

A substitute for this profile may be what is transfenred between the oontext transfer 
manages. The use of the Generic user profile (GUP) or a derivate of CC/PP may be 
useful for signaling. Nevertheless the data transferred may not be a direct copy of the 
original user profile located in the database of the home contact transfer rhanager 200. 
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At least the user's identity may be replaced by a temporary pseudonym that allows to 
identify a user's session and to account the delivered services for the pseudonym, but 
does not allow infomnation gathering about user!s habits or movement pattern across 
multiple sessions. Further all data that has no influence on the context generation 
process may be stripped from the temporary profile transfenred by the home context 
transfer rrianager 200 to the visited context transfer manager 600. 

The transfer of the. temporary user prdfile may be secured using encryption. The 
encryption process may supply confidentiality as well as integrity protection. 
Confidentiality alone may still allow an attacker to insert bogus data into the user profile, 
which may serve as a Denial of Service (DoS) attack. The secure connection itself may.- 
be established using the Security Association that exists between the two operators. A 
specific application protocol for the data may not be needed. 

The recommended mode for context transfer may be the pro-active mode, as it is less 
time. critical. However it is also possible to use the reactive mode. In this casa the mobile 
node 207 requests a context transfer after the start of the handover process. The context 
transfer manager 200, 600 may receive the request through, the new access network 
221, 621 and may i^etum the context of the mobile node 207 to the access network 
context rnanager 209, 210, 211, 609, 610, 611. The context transfer manager 200, 600 
may be able to keep the response time short by tracking the movement of the mobile 
node 207 and by pre-processing and caching of context for the neighbors. 

An example of a context transfer process from an external AAA server with context 
transfer functions (CTM, context generator 201 etc.). to the Authentication Server (AS) or 
access router of a WLAN will be given in the following in referencie to Fig. 4. 

The following assumptions may be made for the example: The mobile node is allowed to 
.use the WLAN by an agreement befeveen WLAN aret 3GPP operator. The mobile node's 
home operator has sufficient information about the capabilities of the WLAN, stored in a 
database and has the technical capability to derive the needed cryptographic data. The 
mobile node is In the state of being connected to an access network and not yet 
beginning a handover to a new access network. Further the Authentication Server (AAA) 
in ttie WLAN is enabled to send the lAPP.CACHE-NOTIFY message to access points, 
requesting the AP to insert a context entry for a mobile node in its cache, a message that 
is nomially exchanged in IEEE 802.1 1f-D5 " Recommended Practice for Multi-Vendor 
Access Point; Interoperability via an Inter-Access Point Protocol Across Distiibutiorl 
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Systems Supporting IEEE 802.11 Operation". IEEE Draft. January 2003, networks 
between two access points. 

The AAA server may transfer 401 a suitable cpntext to the Authentication Servers of the 
WLANs that were detected as neighbors by the Neighbor Selection process. Next, the . 
AAA server.may inform 402 the UE .(l.e. the mobility manager in the mobile tenninal) via 
the current link of Its context parameters (e.g. the Pairwise Master Key, the SSlDs of the 
WLANs etc.) for the next possible connections to other access networks. The context 
parameters may be usable for Intra-WLAN "feature contexts' as well. Other liidependent 
context fields may also be included. 

Every neighboring Authentication Server that received the context with valid data may . 
initiate ^n lAPP.CACHE-NOTIFY message 403 to all relevant Access points containing 
the received context. Every WLAN access point may have an application that reads the 
delivered context in an lAPP.CACHE-NOTIFY message and inserts the wntext. which 
may In our case be a Painwise Master Key (PMK) Security Association (SA) into the PMK 
SA table. For the access point it now seems as the mobile node has gone through the 
key establishing process which would usually be ^^^^^^ new dtent acjcessing 

'ttie access network. 

When the mobile node or client associates 404 with an access point for which It has 
received context data through the former connection. It may directly send the PMKID 
inside the Robust Security Network (RSN) Infomiation Element, which Is listing key 
ciphers, authentication and key management algorithms supported by. the STA (see 
section 7.3.2.9 in IEEE 802.1 1I-D5 "Medium Access Control (MAC) Security 
Enhancements". IEEE Draft. AUgust2003),ofthe association request . 

The access point may then Identify the PMK referenced by the PMKID and directly starts 
the 4-way handshake 405 with the client circumventing the Initial ^^9^ P"^®^: 
saves, "both the authenttatlon handshake access point and the access 

sender and the authentication handshake between the WLAN access sen«r and the AAA 
server. 

The 4-way-handshake between client and access point generates fresh, temporary 
Palnwise and Group keys (PTK and GTK) to secure the following linicast and multicast 
user data transfers. If the client further roams 406 Inside the extended service set (ESS) 
an ongoing context transfer In the WLAN may be accomplished by internal mechanisms 
without the interaction of distant AAA server. 
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The context transfer process between the AAA server and the Authentication Server In 
the WLAN is identical for HPLMN and VPLMN AAA servers. This may be accomplished 
by the handolT of context transfer management between the context transfer managers in 
the home and visited domain. The WLAN Authentication Server rtiay not distinguish 
between the original and the post-processed context from the proxy context transfer 
manager.' It may only differentiate between context data from untrusted or trusted 
sources.. 

It may be possible that the listed process fails because of a timeout of the Security 
Association in the access point's PMK security association cache or a completely failed 
context transfer to the WLAN. In this case the 4-way handshake fails and the normal, 
authentication procedure using e.g. the Extensible Authentication Protocol (EAP) 
handshake is started. For this handshake an EAP mechanism that allows mutual 
authentication may be used. In our example given, mutual authentication may be 
provided using mechanisms as describe in the IETF drafts EAP-SIM and EAP-AKA (see 
Haverinen et al., "EAP SIM Authentication", IETF Internet Driaft, October 2003. and 
Arkko et aL, "EAP AKA Authentication", IETF Internet Draft, October 2003). They use the 
cryptographic functions In the SIM (Subscriber Identity Module) or-USIM (UMTS SIM) 
cards for user identification and key generation. 

The generation of the PMK security association data, will be explained in further detail in 
the following sections. The standard mechanism uses a hash function .(HMAC-SHA1- 
128) to create the PMKID. The hash function is a one-way function, so it cannot b^ used 
to retrieve the source information for the hash algorithm directly. A hash function only 
allows checking if a hash function with unknown input parameters has come to the same 
result as a reference hash function with known input parameters. If the results are 
Identical then the input parameters must also have been identical. For PMKID 
generation, the values PMK, PMK Name, BSSID (basic service set. identification) and 
client's I^C address may be taken as input values^ for the hasH functiorT. These values 
are available to an access point when a client attaches to it So the access point may 
create the complete PMK security association entry. In our example, this entry may not 
be created by a local access point but the context transfer manager 200 may create the 
entry. The context transfer manager 200 may have knowledge about the SSID of the 
WLAN through its access network capabilities database, but it has no knowledge about 
the access points, especially their BSSIDs, in the access network the client roams to. 
This implies that the context transfer manager 200 may not use the BSSID In the 
calculation of the PMKID with the HMAC-SHA1 algorithm. 
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One solution may be to defer the PMKID calculation and thus the context transfer to the 
access network until the client has heard the BSSID and SSID through beacon 
messages and before It has already switched to this access, network. The mobility 
manager 208 may then send the detected BSSID and SSID back to the context transfer 
manager 200 that determines the access network by the SSID. 

According to another "embodiment of the present inventions the context transfer manager 
200 may calculate the PMKID and makes the context transfer to tiie access network's 
context transfer manager 200 and through this to the access, point with the detected 
BSSID. It may be likely that the cont^ does not reach the access point which would 
result, in a reactive context transfer, again. A single cpntext message for every access 
point in the access network may be send. This may require complete knowledge of the 
WLAN infrastructure for ttie context transfer manager 200, which canriot be expected. 

Another solution for the problem of generating a PMK security association may be to 
delegate the processing of the. PMKID to the context manager 209, 210. 211 In tiie 
WLAN. The context manager 209, 210, 211 may send tiie calculated PMKID. to the 
access point together witti ttie clients additional context received frorri the context 
transfer manager 200. The client itself may have calculated the same PMKID witii ttie 
infonnation on tiie access network received through the mobility manager 208 from tiie 
context transfer manager 200 and tiie detected BSSID in WLAN beacons. This solution 
takes tiie load of PMKID calculation fnam tiie context tiansfer manager 200 and 
distributes it to WLAN context manager 209. 210, 211 and the mobile client 207, which 
may result in a performance issue only. The client should be able to perform tiie 
calculation anyway, in case contact bransfer fails. 

For WLAN the PMKID only serves as a unique and unpredictable Identifier lor selecting a 
PMK Security Association out of a cache. The validity of tiie Security Association itself 
may be checked inside ttie 4-way handshake (see Fig. 4) with a challenge/response 
technique using tiie PMK tiiat is never exchanged between ttie peers. A right guess of a 
PMKID of a rogue client thus still does not compromise a Pairwise Master Key. This may 
allow a shortcut for our problem of not being able to calculate the correct PMKID. The 
context transfer manager 200 may generate a random 128 bit number as the PMKID 
wiUiout using the hash function. This shortcut may implies two issues: first the PMKID 
may be propagated from the context ti-ansfer manager 200 tiirough the WLAN pontext 
manager 209, 210, 211 to tiie access point, second, tiiere may be a probability of 
collision between the randomly generated PMKID and the entries in the local PMK 
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security association cache of an access point. The following sections provide an estimate 
of the probability for a collision: 

It may be assumed that the HMAC-SHA1 algorithm creates equally distributed hash 
values. The PMKID has 128 bits, which leads to 3. 4- YO^^ possible values and gives the 
probability of P(x)^2.91Cf^^ for a distinct value to be drawn. For our case this means, our 
randomly calculated PMKID matches the PMKID entry in a cache containing one entry 
with this probability P(colHsion)-P(x)- 2.9'10^^. If we assume a cache size of n PMKID 
entries, the probability for a collision gets P(collision)^h'P(x)-n^ 2.9 10^^. For 1000 cache 
entries this results in a probability of P(colHsion)^ 2.9 1Cf^^ which is still a very small 
probability. 

As a benefit the context transfer manager 200 may distribute the PMKID beforehand and 
neither the client nor the WLAN context manager 209, 210, 211 may have to calculate 
the PMKID itself saving processing time and power and possibly shorten the time until 
the association request from the client may be ready to send to the access point. For the 
WLAN context manager 209, 210, 21 1 this may imply sending the same context data set 
to. all needed access points and notjto calculate a spedfic context for any access point 

Next,' an overview over the context transfer mech.antsm proposed by the present 
invention according to another embodiment will be outlined in reference to the flowchart 
shown in Fig. 5. The context transfer manager 200 may receive 501 location information 
to be evaluated from the mobile node 207 or aft AAA accessible by the context transfer 
manager 200. Upon receiving the location information from a delivering source, the 
context transfer manager 200 may pass the infomriation to a function, or means 
determining 502 neighboring access network based on the mobile npde's position, to 
which the- mobile node 207 may connect In case of a handover. This function may for 
example be realized by the neighbor locator 202 as shown in Fig. 2 and 6. 

The neighboring access networks to which the mobile node 207 may connect are for 
example identified by an identifier as ouUined previously. Further, a mobile node's 
identifier may also be included in the information delivered to the next processing step. 
Based on the ID's identifying the neighboring netwprks and the mobile node 207, the 
context transfer manager 200 may use a' context generation function or means to 
dynamically generate 503 a suitable contjext for the neighboring access networks and the 
rnobile node 207 next. It is important to note that depending on the neighboring networks' 
access technologies the contexts generated by the context transfer manager 200 may 



24/30 

differ In their parameters. The mobile node 207 may also receive a context which i6 . 
especially tailored to the Infomiation needed fortiandover as outlined previously. 

Upon having generated the different contexts for the neighboring networks and the 
mpblle node 207, the context transfer manager 200 may transfer 504 all contexts to the 
respective access networl(s and the mobile node 207. 

When receiving 505 the context at the niobile node 207 and for exemplary purposes 
assurriing that the handover to the next access network has not been perfonned yet, the 
mobile node 207 may preconfigure 506 its network devices based on the infomiation 
comprised in the context received from the context transfer manager 200. E.g. in case; of 
using a WLAN interface in a IPv6 network, the mobile tenninal 207 may create 
preconfigure the network interface with a new IP address, the new default gateway, etc. 
such that upon determining 5(07 the access network to join next and upon handover to It, 
the preconflguratlon settings may be taken over and communication to the new access 
network may immediately be started 508 using the new configuration of tlie network 
interface. 

An access network receiving 509 a context from the context transfer manager 200 may 
also use the infomiation therein to prepare 510 the access network for a possibly 
attaching mobile client 207. To be able to associate a specific configuration for an 
attaching mobile client 207, the an identifier may be included in the context transmitted to 
a context manager 209, 210. 211 in an neighboring access network allowing same to 
identify an mobile node 207 upon its attachment to the network and to make use of the 
context infomnation for communication 51 1 . 
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A method for a context transfer in a communication network comprising a 
plurality of heterogeneous access networks (220, 221, 222, 620, 621, 622), 
wherein a mobile terminal (207) is attached to one of the access networks, the 
method comprising the steps of: 

a context transfer manager (200, 600) receiving location infomiation (501 ), • 

the context transfer manager (200, 600) determining neighboring access 
networks (502) for the mobile terminal (207) based on the location information, 

the context transfer manager (200, 600) generating at least one context (503) 
for the neighboring access networks and the mobile tenminal (207), 

the context transfer manager (200, 600) transmitting a context (504) to each of 
the neighboring access networks (220, 221. 222, 620, 621, 622) and the 
mobile terminal (207)^ 

wherein the generation of the at least one context (304) is based on 
capabilities and parameters associated to the mobile temriinal (207) and 
capabilities and parameters of the neighboring access networks (220, 221 , 
222, 620, 621 , 622) taking into account the respective access technology, and 

wherein the context transfer manager (200, 600) common to the plurality of 
heterogeneous access networks (220, 221, 222, 620, 621, 622) in the 
communication network performs the context transfers r^ated to said mobile 
temiinal.(207). 

The method according to claim 1, further comprising the step of the mobile 
terminal (207) receiving, a beacon signal indicating the- presence of another 
access network, perfomning a handover from the current access networic to 
the new access network from which the beacon signal is received. 

The method according to claim 1 or 2, wherein the context (304) generated for 
each of the neighboring access networks (220, 221, 222, 620, 621, 622) and 
the mobile tenminal (207) comprises a static or temporary identifier of the 
mobile terminal (207). 
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The method according to claim 3, wherein the static or temporary Identifier Is 
used by a context manager (209. 210, 211, 60d, 610, 611) In the new access 
network to associate the mobile tenninai (207) to its context received fiom the 
context transfer manager (200, 600); 

The method according to claim 3 or 4, wherein the mobile terminal (207) 
includes the static or temporary Identifier In the data transmitted; to the new • 
access network. 

The method according to one of claims 1 to 5, further comprising the step of 
pre-configuring the mobile temninal (207) based on the context received from 
the context transfer manager (200, 600). 

The method according to one of claims 1 to 6, wher^n the context transfer 
manager (200, 600) receives status Infomiafion from the mobile temninal 
(207), the status infomnatlon indicating ttie quality of service achieved in the 
cun-ent access netvyork and/or Indicates unsuccessful access attempts to at 
least one other access network than ttie current access network. • 

The method according to claim 7, wherein the step of detennining neighboring 
access networks comprises adapting a. selection algorithm used for 
determining the neighboring access networks (220, 221, 222, 620, 621, 622) 
based on the status information from tiie mobile temninal (207). 

The method according to one of claims 1 to 8, further comprising the step of 
the context transfer manager (200, 600) storing infonriation on failed access 
attempte to access networks reported by tiie mobile temninal (207). 

The metiiod according to one of claims 1 to 9, wherein the capabilities and 
parameters associated to tiie mobile dient comprise at least one of 
authentication, authorization and accounting parameters comprising static 
and/or temporary terminal identifiers, user preferences comprising tiie 
requirements for tiie temninal's communications, guaranteed service quality 
parameters, and/or access penm lesions to. services, session data comprising, 
encryption keys, seeds, ciphers and/or header compression ihfomnation, 
terminal capabilities comprising infomiation on the display, network interfaces, 
processing power, supported applications and/or video/audio codecs. 
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11. The method according to one of claims 1 to 10, wherein the capabilities and 
parameters of the neighboring access network comprise at least one of 
access technology specific attributes comprising a radio frequency, data rates, 
charinels, and/or coding schemes, access networic specific attributes 
comprising cryptographic capabilities of the respective access networic, an 
acciess networic identifier, supported quality of service mechanisms, available 
trafTic classes, local services, infomiation portals, and/or public transportation. 

. information. 

12. The method according to one of claims 1 to 11, wherein the location 
information received by the context transfer manager (200, .600) is received in- 
a paging message transmitted by the mobile terminal (207) or by a signalling 
message from an authentication server (206) in the home domain of the 
context transfer manager (200) after an authentication procedure performed 
between the mobile terminal (207) and the authentication server (206). 

13. The method according to one of claims 1 to 12, wherein the location 
Information is based on a geographical location obtained from a location 
determining device or a networic related location determined based on a 
network address and/or networic prefix. - 

14. Tlie method according to one of claims 2 to 13, wherein the handover is 
performed upon having received context information from the context transfer 
manager (200, 600) related to the new access network. 

The method according to one of claims 1 to 13, wherein a markup-language 
based data format is used to describe the context transferred from the context 
transfer manager (200, 600) to the plurality of access networks (220, 221 , 222, 
620, 621 . 622) and the mobile terminal (207). 

The method according to one of claims 1 to 14, furtiier comprising the step of 
an authentication server (206, 606) in a neighboring access network receiving 
the Context from the context transfer manager (200, 600) performing an 
registration and/or authentication procedure of the mobile temiinai (207) .with 
the neighboring access network using the rec^eived context information. 
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The method according to claim 16, wherein the registration and/or 
authentication procedure comprises registering a security key of the mobile 
temilnal (207). 

The method according, to claim 17, further comprising the step of the mobile 
tenninal (207) using the registered security Itey for communication upon 
attaching to the neighboring access networic In which Vne security key has 
l)een registered. 

The method according to one of claims 1 to 18, wherein the context transfer 
manager (600) resides in a visited communication network. 

The method according to claim 19, wherein a context transfer manager (200) 
In a home communication network of tiie mobile temnlnal (207) transmite date 
relevant for the generation of the at least one context to tiie context transfer 
manager (600) of the visited communication networit. 

The mettiod according to one of claims 1 to 20, furUier comprising the step of 
a context manager (209, 210. 211. 609, 610. 611) In an access network 
receiving ttie context from ttie context transfer manager (200, 600), wherein 
the context manager mainteins no conhec^on to another context manager In 
another access networic. 

A context transfer manager (200, 600) in a communication network comprising 
a plurality of heterogeneous access networics (220, 221, 222, 620, 621, 622), 
wherein a mobile terminal (207) is atteched to one of the access networics, tiie 
context transfer manager (200, 600) comprising: 

receiving means forreoeiving location infonmation, 

processing means (202, 602) for detennlnlng neighboring access networics for 
the mobile tenminal (207) based on the tocation infomiation, 

context generation means (201 , 601) for generating at least one context (304) 
. for the neighboring access networics and the mobile temnlnal (207), 

transmitting means for transmitting the respective context to each of tiie 
neighboring access networics and ttie mobile temnlnal (207), 
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wherein the context generation means (201, 601) Is adapted to generate the 
at least one context (304) based on capabilities and parameters associated to . 
the mobile terminal (207) and capabilities and parameters taking into account 
the respective access technology of the neighboring access network, and 

wherein the context transfer manager (200, 600) common to the plurality of 
heterogeneous access networks (220, 221, 222, 620, 621, 622) in the 
communication network performs the context transfers related to said mobile 
temilnal (207). 

The context transfer manager (200, 600) according to daim 22, wherein the 
context transfer manager (200, 600) is adapted to perform the method 
according to one of claims 1 to 21 . 

A mobile terminal (207) in a communication* netwdrk comprising a plurality of 
heterogeneous acoess networks (220, 221, 222, 620, 621, 622), wherein the 
mobile terminal (207) is attached to one of the access networks, the mobile 
terminal being adapted to perform one of the methods accortling to one of 
claims 1 to 21. 
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Abstract 

The present Invention relates to a method for a oontext transfer in a communioatici, 
comprt«ng a plurality of hete«.geneous access networks, wherein a mobrte 
,«mlnai is attached to ooe of the access networks. Further, the present Invention relates 
to a oohtexl transfer manager peribrmlng the method. Moreover, the present invent,on 
relates to a mobUe lemiinai spedally adapted to perfom. the provided method for a 
context trarisfer. To lac«itate a context »Bnsfer between heterogeneous access 
ne^«o.ks. the present invention iritreduces a oontext transfer manager genereting at 
toast one context based on capabilities and parameters associated to the mobile temnlnal 
and capabllitlee and parameters of the neighboring access nrtwori<s taking into account 
the respective access technology. Further the context transfer manager is common to 
the heterogeneous access networks In tte communication network and perfomis the 
context transfers related to a partloular mobile terminal. 




ePO- Munich 

33 

U Nov. 2003 



.a> 




diiisuoueiaj }sn4 





302 



Processing 
Means 



p a> 



8 



304 



303 



Fig>3 



3/6 



1 i 



ill 

a> CO 

8 



5 



ft 




Context Transfer Manager 



receive location data 



location data from AAA 
or mobile client 



(ocation data 



determine neighbouring 
access networks 



mobile tenninallD . 
neighbouring networks ICte 



context for neighbouring 
networics and mobile dient 



context 



mobile tenminal ID 
neighbouring networks IDs 

capabilities/parameters of 
neighboring networks and , 
mobile client. 



transfer context to neighbouring • 
access networtcs and mobile client 



Access 
Network 



Mobile Terminal 



context 



receive context 



context 



receive context 



configure mobile tennlnal 
based on context 



prepare for mobile tenninal 
to attach (context) 



determine new 
access networic 



use context upon 
mobile tenninal attaching 



handover to new access 
networic using respective context 



505 



506 



* 507 



508 



Fig. 5 



S/6 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 



□ IMAGE CUT OFF AT TOP, BOTTOM OR SffiES 

□ FADED TEXT OR DRAWmC 

□ BLURRED OR ILLEGffiLE TEXT OR DRAWING 

□ skewed/slanted images 

□ color or black and white photographs 

□ gray scale documents 

Klines or marks on original document 



ld>REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 
□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




BLACK BORDERS 




